home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000072_owner-urn-ietf _Tue Oct 22 16:55:09 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA15863 for urn-ietf-out; Tue, 22 Oct 1996 16:55:09 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA15858 for <urn-ietf@services.bunyip.com>; Tue, 22 Oct 1996 16:55:02 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA10411  (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 16:54:30 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16592(3)>; Tue, 22 Oct 1996 13:54:11 PDT
  6. Received: by golden.parc.xerox.com id <2759>; Tue, 22 Oct 1996 13:51:55 PDT
  7. To: paf@swip.net
  8. Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  9. In-Reply-To: <v03007806ae92a7506bf1@[194.52.54.141]> (message from Patrik
  10.     Faltstrom on Tue, 22 Oct 1996 09:32:54 PDT)
  11. Subject: Re: [URN] Pre release of URN Syntax document....
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Oct22.135155pdt."2759"@golden.parc.xerox.com>
  14. Date: Tue, 22 Oct 1996 13:51:55 PDT
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Patrik Falstrom wrote:
  21.  
  22. # Exactly my point, but I was not explicit. Lexical equivalence must
  23. # be something that is handled by the resource server for that specific
  24. # namespace. On the URN "level" we can only state some kind of
  25. # very, very simple comparison methods and point out that it is
  26. # the resource service for that namespace that handles the real
  27. # comparison.
  28.  
  29. which sounds like, but isn't the same as, what we wrote for the 'URN
  30. requirements' document in RFC 1737:
  31.  
  32. >   o Simple comparison: A comparison algorithm for URNs is simple,
  33. >     local, and deterministic. That is, there is a single algorithm for
  34. >     comparing two URNs that does not require contacting any external
  35. >     server, is well specified and simple.
  36.  
  37. This was discussed at length. It's true that it would be useful for
  38. those who know about ISBNs to allow both isbn:0-201-10174-2 and
  39. isbn:0210101742, but having a large variety of syntactic equivalences
  40. has a large cost.
  41.  
  42. For example, the NAPTR resolution scheme depends on regular expression
  43. patterns which will not work well if all of the different syntactic
  44. variations of URNs might be allowed.
  45.  
  46. So I disagree with the assertion:
  47.  
  48. # For an ISBN, the followings should be equivalent:
  49. #   isbn:0-201-10174-2
  50. #   isbn:0201101742
  51.  
  52. If you're going to 'grandfather' ISBN numbers, you should do so in a
  53. single unambiguous way.
  54.  
  55. Larry